feat(orchestrator): carry the queue explicitly on every internal payload - #527

## Summary

### Why?

Consumers today learn a message's queue only by loading the referenced entity from storage, and entity IDs are opaque — nothing may parse a queue out of an ID prefix. For storage to become queue-scoped (resolved per queue like every other extension), every consumer must hold the queue before its first storage read, so the queue has to ride on the wire explicitly.

### What?

The internal payload types (`RequestID`, `BatchID`, `BuildID`, `CancelRequest`) gain a `queue` field; the change is additive JSON, and payloads written before the field existed decode with an empty queue. Publishers stamp it from the entity they already hold: start, mergeconflictsignal, batch, speculate, mergesignal, build, buildsignal, and the orchestrator cancel controller; the gateway cancel controller stamps the authoritative queue from the stored request summary, overriding caller input. Consumers guard that a non-empty payload queue matches the loaded entity's queue and reject mismatches as malformed (non-retryable, straight to DLQ) — the guard becomes the routing input once storage is queue-resolved. Buildsignal's re-publish to speculate now partitions by the batch's queue instead of the inherited batch-ID partition key, matching every other speculate publisher and restoring the per-queue serial-processing guarantee that stage relies on.

## Test Plan

✅ `go test ./...` ✅ `make fmt` ✅ `make lint` — new unit tests cover the queue stamp on published payloads and the mismatch rejection guard.